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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present specification shows QoS signalling flows for resource reservation to provide end-to-end QoS. The flows are 
used as bases of developing QoS related protocol descriptions for new and existing specifications. The following two 
types of flows are described: 

1) flows defining the interaction of GPRS session management procedures over the Gn interface, service based 
local policy (SBLP) procedures over the Go interface and QoS interworking (e.g. RSVP) over the Mb interface; 
and 

2) end-to-end flows of RSVP and GPRS bearer level. 

The relationship between SIP/SDP session level and the bearer level (RSVP and GPRS) in flows showing both SIP/SDP 
session level and the bearer level in end-to-end flows are described in 3GPP TS 24.228 [2]. The present specification 
adds detailed flows involving the network interfaces Gn, Go and Mb and also further details the flows with detailed 
RSVP and GPRS bearer level flows not showing the SIP/SDP session level. 

The present specification also describes the mapping of QoS parameters among SDP, UMTS QoS parameters, and QoS 
authorization parameters. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 24.228: "SignalUng flows for the IP multimedia call control based on SIP and SDP; 

Stage 3". 

[3] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3". 

[4] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[5] 3GPP TS 26.234: "End-to-end transparent streaming service; Protocols and codecs". 

[6] 3GPP TS 26.236: "Packet switched conversational multimedia applications; Default codecs". 

[7] 3GPP TS 29.207: "Policy control over Go interface". 

[8] 3GPP TS 23.107: "Quality of Service (QoS) concept and architecture". 

3 Definitions and abbreviations 
3.1 Definitions 

For the purposes of the present document, the terms and definitions as given in 3GPP TR 21.905 [1] apply. 
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3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply: 



COPS 

DEC 

DRQ 

IMS 
PCF 
REQ 
RPT 



Common Open Policy Service protocol 

COPS Decision message 

COPS Delete Request State message 

IP Multimedia CN Subsystem 

Policy Control Function 

COPS Request message 

COPS Report State message 



4 Authorize QoS resources 

4.1 Authorize QoS resources at originating PCF 

This clause covers the Authorize QoS resources procedure at the originating PCF. 



UE 



GGSN 



SDP 



SDR 



P-CSCF 
PCF 



1. Define down-link 
connection info 



SDP 
SDP 



2. Define up-link 
connection info 



3. QoS authorisation 



1 . The P-CSCF(PCF) gets the SDP parameters defined by the originator and identifies the connection 
information needed (IP address of the down link media flow, media ports to be used etc.). 

2. The P-CSCF(PCF) gets the negotiated SDP parameters from the terminating side through SIP signalling 
interaction. The P-CSCF(PCF) identifies the connection information needed (IP address of the up-link 
media flow, media ports to be used etc.). 

3. The P-CSCF(PCF) uses the SDP parameters in order to define the QoS resource authorisation. The PCF 
authorises every media component negotiated for the session. The authorization shall be expressed in 
terms of IP QoS parameters. An authorization token is generated by the PCF and sent to the UE. 

Figure 4.1 : Authorize QoS resources at originating PCF 
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4.2 Authorize QoS resources at terminating PCF 

This clause covers the Authorize QoS resources procedure at the terminating PCF. 



P-CSCF 
PCF 



SDR » 



GGSN 



1. Define up-link 
connection info 
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Define down-link 
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J 
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3. 


QoS at 


thorisation 



UE 



SDP 
SDP 



SDP 



The P-CSCF(PCF) gets the SDP parameters defined by the originator and identifies the connection 
information needed (IP address of the up-link media flow, media ports to be used etc.). An authorization 
token is generated by the PCF and sent to the UE. 

The P-CSCF(PCF) receives the negotiated SDP parameters from the UE. The P-CSCF(PCF) identifies the 
connection information needed (IP address of the down-link media flow, media ports to be used etc.). 
The P-CSCF(PCF) uses the SDP parameters in order to define the QoS resource authorisation. The PCF 
authorises every media component negotiated for the session. The authorization shall be expressed in 
terms of IP QoS parameters. 



Figure 4.2: Authorize QoS resources at terminating PCF 



Resource reservation flows with Service-based local 
policy 



5.1 



Resource reservation without End-to-end RSVP 



This clause defines a mobile originated procedure without End to End RSVP with service based local policy. The 
service based local policy is done via exchange of information through the Go interface. The Go interface allows the 
service based local policy and QoS interworking information to be requested by the GGSN from a PCF. 

The figure 5.1 presents the "Resource Reservation" procedure at PDP context activation to both the Mobile Originating 
(MO) side and Mobile Terminating (MT) side. 
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Enforcement 



-9. Create PDP Res. 



-8. COPS RPT 



Figure 5.1 : Resource reservation withiout End-to-end RSVP 

1. Mapping from SDP to UMTS QoS parameters 

The UE uses the SDP parameters in order to define the UMTS QoS parameter needed to request a PDP context. The 
QoS parameter mapping mechanism is described in clause 7.2. 

2. GPRS: Activate PDP Context Request (UE to SGSN) 

The UE sends an Activate PDP Context Request message to the SGSN with the UMTS QoS parameters The UE shall 
include binding information in the PDP context activation messages to associate the PDP context bearer with policy 
information. The authorization token is sent by the P-CSCF to the UE during SIP signalling. 

3. GPRS: Create PDP Context Request (SGSN to GGSN) 

The SGSN carries out the procedures identified in 3GPP TS 23.060 [4] related to the PDP context activation. 

4. COPS: REQ (GGSN to PCF) 

The GGSN receives the PDP context activation request with the binding information. The GGSN uses the authorisation 
token in order to localise the PCF. The GGSN sends a COPS REQ message to the PCF and includes the binding 
information. 

5. Process Resource Request (PCF) 

The PCF receives the information sent by the GGSN. The PCF identifies the multimedia session by using the binding 
information. The PCF performs an authorization decision. 

6. COPS: DEC (PCF to GGSN) 

The decision taken by the PCF is returned via the COPS DEC message. The DEC message includes the policy 
information to be used by the GGSN in order to perform the policy-based admission control. 
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7. Policy Enforcement (GGSN) 

The GGSN enforces the PCF policy decision based on the received authorization information from the PCF for the 
media flows carried by the PDP context. 

8. COPS: RPT (GGSN to PCF) 

The GGSN sends COPS RPT message back to the PCF and reports its success or failure in carrying out the PCF 
decision. 

9. GPRS: Create PDP Context Response (GGSN to SGSN) 

The GGSN accepts the PDP context request based on the results of the authorisation policy decision enforcement. If the 
requested QoS parameters are not within the authorized QoS, the GGSN either rejects the PDP context activation 
request or downgrades the requested UMTS QoS parameters. 

10. GPRS: Activate PDP Context Accept (SGSN to UE) 

The SGSN sends an Activate PDP Context Accept message to the UE indicating that the PDP context has been 
activated and that the QoS requirements have been authorized successfully for both downUnk and uplink. 

5.2 Resource reservation with End-to-end RSVP 

Editor's Note: This clause is FFS. 



6 Other flows over Go interface 

6.1 Approval of QoS commit 

Through Approval of QoS Commit the PCF makes a final decision to enable the allocated QoS resource for the 
authorized media stream if the QoS resources are not enable at the time they are authorized by the PCF. 

The Approval of QoS Commit procedure is triggered by the P-CSCF receiving a 200 OK message. 

The following figure is applicable to the Mobile Originating (MO) side and the Mobile Terminating (MT) side. 
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GGSN 



P-CSCF 
PCF 



- 1.200 OK 



2. PCF approves 
the QoS Commit 



3. DEC 



4. GGSN opens the 
gate 



6. 200 OK 



5. RPT 



P-CSCF receives the 200 OK message. 

PCF approves the QoS Commit. 

PCF sends a COPS DEC message to the GGSN to open the 'gate' e.g., enable the use of the authorised 

QoS resources. 

GGSN receives the COPS DEC message and opens the 'gate' e.g., enables the use of the authorised 

QoS resources. 

GGSN sends a COPS RPT message back to the PCF. 

P-CSCF forwards the 200 OK message. 

Figure 6.1 : Approval of QoS Commit to both the Mobile Originating (MO) side 
and the Mobile Terminating (MT) side 



6.2 Removal of QoS commit 

The "Removal of QoS commit" procedure is used e.g. when a media component of a session is put on hold. (e.g. in case 
of a media re-negotiation or call hold). The PCF decision of "Removal of QoS commit " shall be sent as a separate 
decision to the GGSN corresponding to the previous "Authorize QoS Resources" request. 

6.2.1 Removal of QoS commit at Session on Hold 

The following figure presents the "Removal of QoS commit" procedure at session on hold to both the Mobile 
Originating (MO) side and the Mobile Terminating (MT) side. 
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GGSN 



2. Hold 



P-CSCF 
PCF 



LHold 



3. PCF removes the 

QoS Commit for 

the session 



4. DEC 



5. GGSN closes the 
related gates 



6. RPT 



1 . P-CSCF receives the Hold message. 

2. P-CSCF forwards the Hold message. 

3. PCF removes the QoS commit for the session. 

4. PCF sends a COPS DEC message to the GGSN to close the related 'gates'. 

5. GGSN receives the COPS DEC message, closes the 'gates'. 

6. GGSN sends a COPS RPT message back to the PCF. 

Figure 6.2.1 : Removal of QoS commit at Session on Hold to both the Mobile Originating (MO) side 

and the Mobile Terminating (MT) side 

6.2.2 Removal of QoS commit at Codec or media flow change or remove 

The following figure presents the "Removal of QoS commit" procedure at Codec or media flow change or remove to 
both the Mobile Originating (MO) side and the Mobile Terminating (MT) side. 
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4. DEC 
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PCF 




__ 


___ 


-<- 


1. 


3. PCF removes the 


QoS Commit for 


the media flow 
V 









Invite 



5. GGSN closes the 
related gate 



6. RPT 



1 . P-CSCF receives the INVITE message for codec or media change, remove. 

2. P-CSCF forwards the INVITE message. 

3. PCF removes the QoS commit for the related media flow. 

4. PCF sends a COPS DEC message to the GGSN to close the related 'gate'. 

5. GGSN receives the COPS DEC message, closes the 'gate'. 

6. GGSN sends a COPS RPT message back to the PCF. 

Figure 6.2.2: Removal of QoS commit at codec or media flow change 
or remove to both the Mobile Originating (MO) side and the Mobile Terminating (MT) side 



6.3 



Revoke authorization for GPRS and IP resources 



The "Revoke Authorization for GPRS and IP resources" procedure is used e.g. upon session release. The PCF decision 
of "Revoke Authorization for UMTS and IP Resources" shall be sent as a separate decision to the GGSN corresponding 
to the previous "Authorize QoS Resources" request. 

6.3.1 IVIobile initiated session release / Network initiated session release 

The following figure presents the "Revoke Authorization for UMTS and IP Resources" at upon Mobile initiated session 
release / Network initiated session release to both the Mobile Originating (MO) side and the Mobile Terminating (MT) 
side. 
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session 









5. GGSN disables 
the authorization 



6. PDP context 
Deactivation 



7. DRQ 



One mobile party hangs up or the P-CSCF or S-CSCF initiates BYE message. 

P-CSCF forwards the BYE message. 

PCF removes the authorisation for resources that had previously been issued for this endpoint for this 

session. 

PCF sends a COPS DEC message to the GGSN. It includes binding information, which identifies the PDP 

context to be deactivated. 

GGSN receives the COPS DEC message, and disables the use of the authorized QoS resources. 

GGSN initiates deactivation of the PDP context used for the IP multimedia session, in case the UE has not 

done it before. 

GGSN sends a COPS DRQ message back to the PCF. 

Figure 6.3.1 : Revoke authorization for GPRS and IP resources - 

Mobile initiated session release / Network initiated session release 

to both Mobile Originating (MO) and Mobile termination side 



6.4 



Indication of PDP Context Release 



The "Indication of PDP Context Release" procedure is used upon the release of a PDP Context that was established 
based on authorisation from the PCF in e.g. accidental/malicious removal of a PDP Context that is related to an IMS 

session. 

The following figure presents the "Indication of PDP Context Release" to both the Mobile Originating (MO) side and 
the Mobile Terminating (MT) side. 
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2. DRQ 



3. PCF may remove 

the authorization for 

the session 



1 . SGSN deactivates the PDP context related to the media flow by sending the Delete PDP Context Request 
message to the GGSN. 

2. GGSN sends a COPS DRQ message to the P-GSGF(PGF). 

3. P-CSCF(PGF) receives the GOPS DRQ message and PGF may remove the authorization for the session. 

4. GGSN sends the Delete PDP Context Response message to the SGSN to acknowledge the PDP context 
deletion. 

NOTE: Step 4 may also occur at the same time or before Step 3. 

Figure 6.4.1 : Indication of PDP Context Release to both the Mobile Originating (IVIO) side 

and the lUlobile Terminating (IVIT) side 

The following figure presents the case when the GGSN initiates the release of a PDP context, i.e. after an error 
condition has been detected in GGSN. 
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1 . GGSN sends a COPS DRQ message to the P-CSCF(PCF). 

2. GGSN deactivates the PDP context related to the media flow(s) by sending the Delete PDP Context 
Request message to the SGSN. 

3. SGSN sends the Delete PDP Context Response message to the GGSN to acknowledge the PDP context 
deletion. 

4. P-CSCF(PCF) receives the COPS DRQ message and PCF may remove the authorization for the media 
flow(s) authorized for this PDP context. 

NOTE: Step 4 may also occur at the same time or before Step 2 and Step 3. 

Figure 6.4.2: Indication of GGSN-initiated PDP Context Release to both 
the Mobile Originating (MO) side and the Mobile Terminating (MT) side 



6.5 



Modification of PDP Context 



The "Modification of PDP Context" procedure is used when a PDP Context is modified such that the requested QoS 
falls outside of the limits that were authorized at PDP context activation (or last modification) or such that the 
maximum bit rate (downlink and uplink) is downgraded to kbit/s. In these cases, the GGSN communicates with the 
PCF as described below. 

6.5.1 Authorization of PDP Context IVIodification 

The figure 6.5.1 presents the "Modification of PDP Context" procedure to both the Mobile Originating (MO) side and 
the Mobile Terminating (MT) side when the UMTS QoS which were authorized at PDP context activation (or last 
modification) has been changed by UE. 



£75/ 



3GPP TS 29.208 version 5.0.0 Release 5 



16 



ETSI TS 129 208 V5.0.0 (2002-06) 



SGSN 



GGSN 



1 . Update PDP 
Context Request 



c 



P-CSCF 
PCF 



■ 2. COPS REQ 



3. Process 
resource 
request 



-4. COPS DEC 



5. Policy 
Enforcement 



-6. COPSRPT 



7. Update PDP 
Context Response 



1 . A request to modify the PDP context related to the media flow is indicated by sending the Update PDP 
Context Request message to the GGSN with the changed UMTS QoS parameters. 

2. If the GGSN supports a Local Policy Decision Point{LPDP), it can consult the local policy decision stored in 
the LPDP before sending the COPS REQ message to the PCF. In case the requested QoS is within the 
already authorized QoS and the binding information is not changed, the GGSN does not need to send an 
authorization request to the PCF and proceeds to step 5. Qtherwise, the GGSN sends a CQPS REQ 
message to the PCF. 

3. The PCF receives the CQPS REQ message and performs an authorization decision according to the 
requested modification. 

4. The decision taken by the PCF is returned via the CQPS DEC message. The DEC message includes the 
policy information to be used by the GGSN in order to perform the policy-based admission control. 

5. The GGSN enforces the policy decision based on the authorization information cached on the GGSN 
LPDP or received from the PCF for the media flows carried by the PDP context. 

6. The GGSN sends CQPS RPT message back to the PCF and reports its success or failure in carrying out 
the PCF decision and notifies state changes if any. 

7. The Update PDP Context Response message is sent to the SGSN to acknowledge the PDP context 
modification. 

Figure 6.5.1 : Authorization of PDP Context IVIodification to both the IVIobile Originating (IVIO) side 

and the IVIobile Terminating (MT) side 

6.5.2 Indication of PDP Context Modification 

The figure 6.5.2 presents the "Indication of PDP Context Modification" procedure to both the Mobile Originating (MO) 
side and the Mobile Terminating (MT) side when the maximum bit rate (downlink and uplink) for the PDP context is 
modified to and from kbit/s. 
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1 . SGSN modifies the PDP context related to the media flow{s) by sending the Update PDP Context Request 
message to the GGSN. 

2. GGSN sends a COPS RPT message to the PCF notifying the PDP context modification. 

3. PCF receives the COPS RPT message and forwards the indication to the P-CSCF. 

4. GGSN sends the Update PDP Context Response message to the SGSN to acknowledge the PDP context 
modification. 

NOTE: Step 4 may also occur at the same time or before Step 3. 

Figure 6.5.2: Indication of PDP Context Modification to both the Mobile Originating (MO) side 

and the Mobile Terminating (MT) side 



7 QoS parameter mapping 

7.1 QoS parameter mapping between IIVIS and GPRS 

Within the IM sub-system, session estabHshment and modification involves an end-to-end message-exchange using 
SIP/SDP with negotiation of Codecs as defined in 3GPP TS 24.229 [3] and 3GPP TS 24.228 [2]. Upon completion of 
the negotiation, the P-CSCF shall forward the relevant SDP information to the PCF. The PCF notes and authorises the 
chosen media flows and Codec preference, maps from SDP parameters to Authorized IP QoS parameters for transfer to 
the GGSN via the Go interface. The GGSN will map from the Authorized IP QoS parameters to the Authorized UMTS 
QoS parameters. The SIP/SDP message will also have been passed on to the UE, where the UE will perform its own 
mapping from the SDP parameters and applications to some UMTS QoS Parameters in order to populate the requested 
QoS field within the PDP context activation or modification. If the SDP parameters are received in an IMS context the 
UE will also map from the SDP parameters to some Authorized UMTS QoS parameters. Upon receiving the PDP 
context activation or modification, the GGSN shall compare the UMTS QoS parameters against the Authorized UMTS 
QoS parameters. If the request lies within the limits authorised by the PCF, the PDP context activation or modification 
shall be accepted. 

Figure 7.1 indicates the network entities where QoS mapping functionality is required. This mapping is performed by: 

1 . The PCF maps from the SDP parameters determined from the SIP signalling to the Authorized IP QoS 
parameters that shall be passed to the GGSN via the Go interface (see clause 7.1.1). 

2. The GGSN maps from the Authorized IP QoS parameters received from PCF to the Authorized UMTS QoS 
parameters (see clause 7.1.2). The GGSN compares then the UMTS QoS parameters of the PDP context against 
the Authorized UMTS QoS parameters (see clause 7.1.3). 

3. The UE in which a mapping is made from the SDP parameters to some UMTS QoS parameters (see clause 7.2.1) 
and, if the SDP parameters are received in an IMS context, also to some Authorized UMTS QoS parameters (see 
clause 7.2.2). 

The mapping that takes place in the UE and the network shall be compatible in order to ensure that the GGSN will be 
able to correctly authorise the session. 
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SDP parameters to Authorized IP QoS parameters mapping. 

Authorized IP QoS parameters to Authorized UMTS QoS parameters mapping. 

SDP parameters to UIVITS QoS parameters/Authorized UIVITS QoS parameters mapping. 

Figure 7.1 : Framework for QoS mapping between IIVIS and GPRS 



7.1 .1 SDP parameters to Authorized IP QoS parameters mapping in PCF 

The QoS authorization is to be based on the parameters Maximum Authorized DiffServ PHB and Maximum Authorized 
Data Rate UL/DL. 

The PCF shall use the mapping rules in table 7.1.1.1 to derive the Authorized IP QoS parameters Maximum Authorized 
Data Rate DL/UL and the Maximum Authorized DiffServ PHB from the SDP Parameters. 
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Table 7.1.1.1 : Rules for derivation of the Maximum Authorized Data Rates 
and Maximum Authorized DiffServ PHB per media flow in the PCF 



Authorized IP 
QoS Parameter 
per media flow 


Derivation from SDP Parameters 


Maximum 
Authorized Data 
Rate DL and UL 
per media flow 
(see note 1) 


/* Check if the media use codec(s) 7 

IF [(<media> = ("audio" or "video")) and (<transport> = "RTP/AVP")] THEN 

/* Check if Streaming 7 

IF a=("sendonly" or "recvonly") THEN 

Maximum Authorized Data Rate DL/UL per media flow is set equal to Maximum Bitrate 
DL/UL. See reference [5] ; 

Editor's note: Whether Maximum Authorized Data Rate per media flow is set to Maximum or 
Guaranteed Bitrate is ffs. 

/* Conversational as default 17 

ELSE 

Maximum Authorized Data Rate DL/UL per media flow is set equal to Maximum Bitrate 
DL/UL. See reference [6] ; 

Editor's note: Whether Maximum Authorized Data Rate per media flow is set to Maximum or 
Guaranteed Bitrate is ffs. 

ENDIF; 

/* Check for presence of bandwidth attributes 7 
ELSEIF b=AS:<bandwidth-value> is present THEN 
Maximum Authorized Data Rate DL/UL per media flow = "bandwidth-value" ; 

/* SDP do not give any guidance! / 
ELSE 

Maximum Authorized Data Rate DL/UL per media flow is set according to operator policy ; 
ENDIF; 


Maximum 
Authorized 
DiffServ PHB per 
media flow 
(see note 2) 


IF [(<media> = ("audio" or "video")) and (a="sendrecv")] THEN 

Maximum Authorised DiffServ PHB per media flow = "EF" ; 
ELSEIF [(<media> = ("audio" or "video")) and (a=("sendonly" or "recvonly"))] THEN 

Maximum Authorised DiffServ PHB per media flow = "AF4" ; 
ELSEIF <media> = ("application" or "control") THEN 

Maximum Authorised DiffServ PHB per media flow = "AF3" ; 
ELSE Maximum Authorised DiffServ PHB per media flow = "BE" ; 
END; 


NOTE 1 : For a RTP media flow the Maximum Authorized Bandwidth DL/UL are the sum of the RTP flow DL/UL and 

the associated RTCP flow DL/UL. 
NOTE 2: The Maximum Authorized Traffic Class for a RTCP flow is the same as the corresponding RTP flow. 



The PCF shall per ongoing session store the Authorized IP QoS parameters per media flow. 

When the GGSN requests the Authorized UMTS QoS parameters for an activated/modified PDP Context carrying one 
or more media flows (eventually with associated RTCP signalling), the PCF shall use the rules in table 7.1.1.2 to 
calculate the Authorized IP QoS parameters. 



£75/ 



3GPP TS 29.208 version 5.0.0 Release 5 



20 



ETSI TS 129 208 V5.0.0 (2002-06) 



Table 7.1 .1 .2: Rules for calculating the Maximum Authorized Data Rate 
and IVIaximum Authorized Diffserv PHB Parameters per Binding Information in the PCF 



Authorized IP 

QoS Parameter 

per Binding 


Calculation Rule 


Maximum 
Authorized Data 
Rate DL and UL 
per Binding 
Information 


Maximum Authorized Data Rate DL/UL per Binding Information is the sum of all Maximum 
Authorized Data Rate DL/UL per media flow for all the media flows identified by the Binding 
Information 

IF Maximum Authorized Data Rate DL/UL per Binding Information > 2047 kbps THEN 

Maximum Authorized Data Rate DL/UL per Binding Information = 2047 kbps /* See ret [8] 7 

END; 


Maximum 
Authorized 
Diffserv PHB per 
Binding 
Information 


Maximum Authorized Diffserv PHB per Binding Information = MAX [Maximum Authorized Diffserv 
PHB per media flow among all the media flows carried by the current PDP Context] 

(The MAX function ranks the possible Maximum Authorized Diffserv PHB values as follows: "EF" 
> "AF4" > "AF3" > "BE") 



7.1 .2 Authorized IP QoS parameters to Authorized UMTS QoS 
parameters mapping in GGSN 

The Translation/Mapping function in the GGSN shall derive the Authorized UMTS QoS parameters from the 
Authorized IP QoS parameters received from the PCF according to the rules in table 7.1.2. 

Table 7.1.2: Rules for derivation of the Authorized UMTS QoS Parameters 
from the Authorized IP QoS Parameters 



Authorized 
UMTS QoS 
Parameter 



Derivation from Authorized IP QoS Parameters 



Maximum 
Authorized 
Bandwidth DL 
andUL 



Maximum Authorized Bandwidth DL/UL = Maximum Authorized Data Rate DL/UL 



Maximum 
Authorized 
Traffic Class 



IF Maximum Authorized Diffserv PHB = "EF" THEN 
Maximum Authorized Traffic Class = "Conversational" 

ELSEIF Maximum Authorized Diffserv PHB = "AF4" THEN 
Maximum Authorized Traffic Class = "Streaming" 

ELSEIF Maximum Authorized Diffserv PHB = "AF3" THEN 
Maximum Authorized Traffic Class = "Interactive" 

ELSE Maximum Authorized Traffic Class = "Background" 
ENDIF; 



7.1 .3 Comparing UMTS QoS Parameters against the Authorized UMTS 
QoS parameters in GGSN 

Upon receiving a PDP context activation, the UMTS BS Manager in the GGSN requests the Authorized UMTS QoS 
parameters from the PCF, and might request the Authorized UMTS QoS Parameters if a PDP context is modified (see 
[7] for details). The GGSN compares the requested UMTS QoS parameters against the corresponding Authorized 
UMTS QoS parameters. If all the requested parameters lie within the limits, the PDP context activation or modification 
shall be accepted. If any of the requested parameters do not lie within their respective limit, the GGSN shall either reject 
the activation or modification of the PDP context or downgrade the requested UMTS QoS parameters. 



£75/ 



3GPP TS 29.208 version 5.0.0 Release 5 



21 



ETSI TS 129 208 V5.0.0 (2002-06) 



7.2 QoS parameter mapping in the UE 

Figure 7.2 indicates the entities participating in the generation of the requested QoS parameters when activate or modify 
a PDP Context in the UE. The steps are: 

1. The AppUcation provides the UMTS BS Manager, possibly via the IP BS Manager and the Translation/Mapping 
function, with relevant information to perform step 2 or step 4. (Not subject to standardization within 3GPP). 

2. If needed, information from step 1 is used to access a proper set of UMTS QoS Parameters. See 3GPP TS 26.236 
[6] for Conversational Codec Applications and 3GPP TS 26.234 [5] for Streaming Codec Applications. 

3. If SDP is present then the SDP Parameters might give guidance for the UMTS BS Manager to set the Maximum 
Bitrate UL/DL, Guaranteed Bitrate UL/DL and the Maximum SDU Size. The Application deliver extracted SDP 
information, possibly via the IP BS Manager, to the Translation/Mapping function. The Translation/Mapping 
function finally derives the UMTS QoS parameters according to the rules in clause 7.2.1. Furthermore if the SDP 
Parameters are received in an IMS context it is recommended that the Maximum Authorized Bandwidth UL and 
DL and Maximum Authorised Traffic Class are derived according to the rules in clause 7.2.2. 

4. A set of UMTS QoS Parameters values from step 2 (or directly from step 1) is eventually merged together with 
the Maximum Bitrate UL/DL, the Guaranteed Bitrate UL/DL and the Maximum SDU Size from step 3. The 
result constitutes a recommendation of requested UMTS QoS Parameters. If the PDP Context is activated or 
modified in an IMS context it is recommended that the UE checks that the actual requested Maximum Bitrate 
UL/DL are not greater than the Maximum Authorized Bandwidth UL/DL. Furthermore, if the UE has 
implemented the mapping rule for Maximum Authorized Traffic Class, as defined in clause 7.2.2, it is also 
recommended that the requested Traffic Class is not greater than the Maximum Authorised Traffic Class derived 
in step 3. 
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Figure 7.2: Framework for generating requested QoS parameters in the UE 
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7.2.1 SDP to UMTS QoS parameter mapping in UE 

If SDP Parameters are available, then before activating or modifying a PDP Context the UE should check if the SDP 
Parameters give guidance for setting the requested UMTS QoS Parameters. The UE is recommended to use the 
mapping rules in table 7.2.1 to derive the Maximum and Guaranteed Bitrate DL/UL and Maximum SDU Size from the 
SDP Parameters. 

Table 7.2.1 : Recommended rules for derivation of the requested Maximum 
and Guaranteed Bitrate DL/UL and the requested Maximum SDU Size in the UE 



UMTS QoS Parameter 


Derivation from SDP Parameters 


Maximum Bitrate DL/UL 

and 

Guaranteed Bitrate 

DL/UL 


/* Check if the media use codec{s) 7 

IF [(<media> = ("audio" or "video")) and (<transport> = "RTP/AVP")] THEN 

/* Check if Streaming 7 

IF a= ("sendonly" or "recvonly") THEN 

IVIaximum Bitrate DL/UL and Guaranteed Bitrate DL/UL as specified in reference 
[5]; 
/* Conversational as default 17 
ELSE 

IVIaximum Bitrate DL/UL and Guaranteed Bitrate DL/UL as specified in reference 
[6]; 
ENDIF; 

/* Check for presence of bandwidth attribute 7 
ELSEIF b=AS:<bandwidth-value> is present THEN 

IVIaximum Bitrate DL/UL and Guaranteed Bitrate DL/UL = "bandwidth-value" ; 
ELSE 

/* SDP do not give any guidance ! 7 

IVIaximum Bitrate DL/UL and Guaranteed Bitrate DL/UL as specified by the UE 

manufacturer; 

ENDIF; 


Maximum SDU size 


/* Check if the media use codec(s) 7 

IF [(<media> = ("audio" or "video")) and (<transport> = "RTP/AVP")] THEN 

/* Check if Streaming 7 

IF a= ("sendonly" or "recvonly") THEN 

Maximum SDU Size as specified in reference [5] ; 

/* Conversational as default 17 
ELSE 

Maximum SDU Size as specified in reference [6] ; 
ENDIF; 

ELSE 

Maximum SDU Size as specified by the UE manufacturer ; 

ENDIF; 



7.2.2 SDP parameters to Autlnorized UMTS QoS parameters mapping in 
UE 

If the PDP Context is activated or modified in an IMS context then it is recommended that the UE uses the mapping 
rules in table 7.2.2.1 to derive the Maximum Authorized Bandwidth UL/DL. 

Table 7.2.2.1 also has a mapping rule for derivation of Maximum Authorized Traffic Class. In future releases this 
mapping rule may change. For the reason of future compatibility, the release 5 mapping rule is optional for the UE. 

In the case this mapping rule is implemented then it is recommended that the UE use the mapping rule in table 7.2.2. 1 to 
derive the Maximum Authorised Traffic Class from the SDP Parameters. 
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Table 7.2.2.1 : Rules for derivation of the IVIaximum Authorized Bandwidth DL/UL 
and the lUlaximum Authorized Traffic Class per media flow in the UE 



Authorized UIMTS QoS 

Parameter per media 

flow 


Derivation from SDP Parameters 


IVIaximum Authorized 
Bandwidth DL and UL 
per media flow 


/* Check if IMS context (the criteria for this check is an UE manufactures issue ) 7 
IF IMS context THEN 

/* Check if the media use codec(s) 7 

IF [(<media> = ("audio" or "video")) and (<transport> = "RTP/AVP")] THEN 

/* Check if Streaming 7 

IF a=("sendonly" or "recvonly") THEN 
Maximum Authorized Bandwidth DL/UL set equal to Maximum Bitrate DL/UL. See 
reference [5] ; 

Editor's note: Whether Maximum Authorized Bandwidth is set to Maximum or Guaranteed 
Bitrate is ffs. 

/* Conversational as default !7 

ELSE 

Maximum Authorized Bandwidth DL/UL set equal to Maximum Bitrate DL/UL. See 
reference [6] ; 

Editor's note: Whether Maximum Authorized Bandwidth is set to Maximum or Guaranteed 
Bitrate is ffs. 

ENDIF; 

/* Check for presence of bandwidth attributes 7 
ELSEIF b=AS:<bandwidth-value> is present THEN 

Maximum Authorized Bandwidth DL/UL = "bandwidth-value" ; 

/* SDP do not give any guidance! / 
ELSE 
Maximum Authorized Bandwidth DL/UL as specified by the UE manufacturer ; ENDIF ; 

ELSE 

No authorization is done ; 
ENDIF; 


IVIaximum Authorized 
Traffic Class per media 
flow 


/* Check if IMS context (the criteria for this check is an UE manufactures issue ) 7 

IF IMS context THEN 

IF [(<media> = ("audio" or "video")) and (a="sendrecv")] THEN 

Maximum Authorised Traffic Class = "Conversational" ; 
ELSEIF [(<media> = ("audio" or "video")) and (a=("sendonly" or "recvonly"))] THEN 

Maximum Authorised Traffic Class = "Streaming" ; 
ELSEIF <media> = ("application" or "control") THEN 

Maximum Authorised Traffic Class = "Interactive" ; 

ELSE Maximum Authorised Traffic Class = "Background" ; 
END; 

ELSE 

No authorization is done ; 
ENDIF; 



It is recommended that the UE per ongoing session store the Authorized UMTS QoS parameters per media flow. 

Furthermore it is recommended that the UE checks that the requested UMTS QoS parameters Traffic Class and 
Maximum Bitrate UL/DL not exceeds the values of the corresponding Authorized UMTS QoS parameters (calculated 
according to the rules in table 7.2.2.2) before activating/modifying a PDP Context. 
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Table 7.2.2.2: Rules for calculating the Maximum Authorized Bandwidths 
and Maximum Authorized Traffic Class Parameters per PDP Context in the UE 



Authorized 

UMTS QoS 

Parameter per 

PDP Context 


Calculation Rule 


Maximum 
Authorized 
Bandwidth DL 
and UL per PDP 
Context 


/* Check if IMS context (the criteria for this check is an UE manufactures issue ) 7 
IF IMS context THEN 

Maximum Authorized Bandwidth DL/UL per PDP Context is the sum of all Maximum 
Authorized Bandwidth DL/UL per media flow for all the media flows carried by the PDP Context ; 

IF Maximum Authorized Bandwidth DL/UL per PDP Context > 2047 kbps THEN 

Maximum Authorized Bandwidth DL/UL per PDP Context = 2047 kbps /* See ref [8] 7 
END; 

ELSE 

No authorization is done ; 
ENDIF; 


Maximum 
Authorized 
Traffic Class per 
PDP Context 


/* Check if IMS context (the criteria for this check is an UE manufactures issue ) 7 
IF IMS context THEN 

Maximum Authorised Traffic Class per PDP Context = MAX [Maximum Authorised Traffic 
Class per media flow among all the media flows carried by the PDP Context] ; 

ELSE 

No authorization is done ; 
ENDIF; 

(The MAX function ranks the possible Maximum Authorised Traffic Class values as follows: 
Conversational > Streaming > Interactive > Background) 
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